1. Technical Field
This invention relates generally to a method of communicating between devices in networks, and more particularly, to multicast communications protocols for networks.
2. Background of the Invention
Communications protocols provide a set of rules or procedures generally relating to format and timing of data transmission between devices in a computer network. The computer network is formed of host devices which transmit information between one another and are connected by a communications network of switching elements or switching nodes. Multicasting is a form of communication in which a message is received by a subset of hosts within the network. In a point-to-multipoint multicasting environment, a source host device or source node generates and communicates a message with two or more destination or receiving hosts. Multicasting may also involve a multipoint-to-multipoint communication where a subset of sending nodes in the network transmit information to two or more receiving nodes.
Multicasting protocols have been developed to provide a communication framework in a multicasting environment. The Resource Reservation Protocol (commonly referred to as RSVP) is used for providing resource reservation in multicast connections. RSVP is designed to aid a multicast protocol. However, RSVP has been found to be inefficient and problematic especially when the number of receiving host devices is very large. The basic operation of the RSVP is to send a PATH message from the source to the destinations, and the destinations then respond with a RESERVATION message. To establish the connections to multiple receivers, the PATH message is routed according to a routing table in the intermediate switching nodes. Because of different capabilities in the receiving devices, the receivers specify the resource required for accepting the connection. However, the routing path from the source to the destination for the PATH message may not be the same as the other direction for the RESERVATION message. Thus, in the RSVP reverse route, tables are required to be kept in each intermediate switching node to provide the reverse routing table.
When a source host sends out a PATH message to reserve resource, the receivers will respond with a RESERVATION message to reserve the resource for the multicast session. One of the styles in the RSVP protocol requires the switching node (or nodes) to maintain individual source's information for the multicast session. Furthermore, it is required in RSVP to specify the refresh period used by the sender. The switching node uses the specified refresh period as a guideline in attempting to maintain the resource reservation in the switching node. Moreover, the PATH and RESERVATION messages must be exchanged constantly (e.g. every 100 ms) in order to keep the reservation of resources in each intermediate switching node. Disadvantageously however, the receiving nodes are required to continually periodically respond with RESERVATION messages to appropriately reserve the resource.
This constant refreshing scheme of reserving resources is employed to account for state changes in the multicast group such as dynamic routing table changes in the packet data network. By the continuous refreshing of resource reservations, the left over reservations in the switching nodes due to routing table changes are merely flushed out when they are not refreshed within the predetermined time. Unfortunately, the constant refreshing scheme requires an extremely high volume of messages especially at the edge of the network and has shown to be a real-time processing drain for the edge switches. The large message exchanging and real-time intensive processing is significantly problematic and inefficient for large scale multicast groups. Therefore, there is a need in the art for efficiently maintaining correct resource reservation along a multicast path even when network routing is changed at the switching nodes and when other state changes in the network occur.